Prisma を綺麗に使いたければ MVC という発想を忘れるのが良いのでは
他の言語の ORM に慣れた人は（当然のことだが）これに違和感を抱き、機能不足に感じるようだ。
いわく宣言的に validation を書く層がないので結果的に手続き的なベタ書きを助長するし、 #Rails よりも設計が悪化しそうに見えるといった具合である。 で思ったのが、実際に宣言的なバリデーションといったときにやるべきなのってクラスにマッピングすることではないよなってことで。同僚氏がこの点に関して「そこを吸収するのが #GraphQL resolver なんですよ」と言っててすごく納得したことがあった。 #REST + MVC しか知らない人は model クラスがない ＝ controller に手続き的に書くという想像をしてしまうようだが、そもそも controller という層が存在しなくても（ API のレスポンスに責務を持つ層がバリデーション含めたロジックを宣言的に表現できるなら ）良いと考えられるし、それが GraphQL なら resolver なんだとなる。GraphQL はエンドポイント1個しかないんだから controller もへったくれもあるわけないよね！ 極論 Prisma をキレイに使いたければ、サーバーサイド ＝ REST + MVC という無意識の前提が邪魔ということになる（ いわゆる node.js でサーバーサイドをやるのがつらいという話って、結局の所 express で MVC がつらいって話にすぎなくないですか？ ）。ORM を使うこととアーキテクチャが MVC であることは直交するし、model という単語を使うことがそもそも的外れとさえ言えるかも。つまり真に対立している相手は ActiveRecord というより、ORM ＝ MVC の M という考えなんじゃないか（ ActiveRecord と対比されやすいのは、ORM ＝ ActiveRecord パターンという発想もまた多いからだろう ）。
メンタルモデルで言うと resolver は「JSON カラムの1つ1つの内容に責務を持つ宣言的な関数」であり、カラム自身が自分のエラーになる条件を知っているし、どうやって DB の値からキャストされるのか、誰がアクセスして良いのかも自分自身が知っているという考えになりそう。
そうすると、 #Rails でいうfat model ならぬ fat resolver を志向するような #設計 論が出てきてもおかしくないが寡聞にして聞いたことがない（あるいはないってことはここまでの議論は間違っているんだろうか）。知ってたら誰か教えて下さい。